四個極大提升文案質量的技巧（方法）
我們負責 Apple 應用文字內容撰寫。每當有人問我們如何改進應用程式中的文字表達，我們最常給出的建議是“簡化”
1 Remove fillers 移除填充詞
在 UX 寫作中，一個常見誤區是以為必須把介面上的空白填滿。小時候寫作文，要湊字數就拼命用“非常”、“特別”、“極其”這種詞。但App 並沒有字數下限要求反而是字越少越好。
最常見填充詞：adverbs and adjectives 副詞和形容詞
比如 “easily（輕鬆地）” 和 “quickly（迅速地）”就是副詞，用來形容動作。
比如 “fast（快速的）” 和 “simple（簡單的）” 這樣的詞就是形容詞
舉個例子：
我最近度假時，把租來的車停在一個需要透過 App 付款的車庫裡，當時我還沒下載那個 App，所以我得走到出口附近才能有訊號下載，下載好之後，我在 App 裡看到一條提示資訊。
“Simply enter your license plate number to quickly pay for parking.”“只要輸入車牌號，就能快速付款。”
可我租的是車，壓根不記得車牌，只能走回去看。然後又得走回出口找訊號付款，:根本沒他說的那麼簡單和快捷。
如果我把 “simply” 和 “quickly” 刪掉，句子就變成了 “Enter your license plate number to pay for parking.”
這樣改後資訊依然清晰，而且不再對使用者的使用場景做出錯誤假設。最終資訊與原文相似，但透過刪除無用修飾詞，傳達效果反而更有力。
在某些情況下，適當的描述性文字是有用的
舉個例子：
比如有個 App，可以遠端控制寵物餵食機。你用這 App，可以自動喂貓貓狗狗。我可能會寫一句：“Feed your pets when you’re away.”“你不在家也能喂寵物。”
但這句話遺漏了一個關鍵賣點：它能按設定時間每天自動餵食，非常方便。加上“自動automatically”兩個字，使用者馬上就懂這 App 是怎麼工作的。
寫 App 文案時，要抵抗用太多詞來“填滿介面”的衝動。如果你在文案中看到形容性用詞，先停一下，問自己：“這個詞真的有必要嗎？
填充詞：interjections and pleasantries 感嘆詞和客套話
比如 “oops（哎呀）”、“oh no（糟糕）” 和 “hooray（太棒了）”
客套話是像 “sorry（對不起）”、“thank you（謝謝）” 和 “please（請）” 這樣的用語。雖然這些詞可能讓你的 App 看起來更有“人情味”，但如果它們並不傳達實質資訊，最好還是刪掉。
舉個例子：
有人正在等待快遞，然後收到了一個通知
“Uh oh. We’re running late,” “We’re sorry, your delivery driver won’t make it on time. They’ll be there in 10 short minutes! Check the app for your driver’s location.”
通知標題寫著：“呃哦，我們遲到了。”正文部分是：“很抱歉，你的配送員可能無法準時送達。他將在短短 10 分鐘內抵達！你可以在 App 中檢視配送員的位置。”
想改進這段話，咱們先從刪“填充詞”開始：
- 像 “uh oh（哎呀）”、“oops（哎呦）”、“oh no（糟了）” 這類感嘆詞如果出現在錯誤資訊中，會讓人覺得你不夠重視問題。
- 正文裡的 “We’re sorry（我們很抱歉）” 其實沒有必要，遇到問題我們當然習慣性想道歉，但像這樣的通知裡，道歉可能顯得不真誠，反而讓人忽略了真正重要的資訊。
- 正文還說了 “10 short minutes（短短 10 分鐘）！雖然 10 分鐘聽起來不長，但對等待快遞的人來說可能至關重要，加上感嘆號反而讓這個延誤看起來像是件小事，避免使用那些其實沒傳達實質意義、只是“看起來有情緒”的標點符號
我把廢話刪了之後，這段話立刻就清爽多了：
“We’re running late. Your delivery driver won’t make it on time. They’ll be there in 10 minutes. Check the app for your driver’s location.”
“我們晚點了。你的快遞員無法準時送達。他將在 10 分鐘內抵達。請在 App 中檢視快遞員位置。”
2 Avoid repetition 避免重複表達
在 App 中，重複的語言也是一種填充詞，別為了“看起來有內容”就換著說法重複講一樣的事。回到剛才那個快遞來晚了的例子。
“We’re running late” “Your delivery driver won’t make it on time” “in 10 minutes.”
標題“我們遲到了”和正文中“你的配送員無法準時送達”再加上“10 分鐘內到達”這幾句，其實都在說同一件事：快遞會晚一點
“Delivery delayed 10 minutes.”我可以把這些資訊合併成一句，比如把標題改為“配送延遲 10 分鐘”這樣一句話就同時說明了“發生了延遲”以及“具體延遲時間”，更高效。正文則可以保留為“請在 App 中檢視配送員的位置”（這是有用的新資訊，沒必要改）
Before：“Uh oh. We’re running late,” “We’re sorry, your delivery driver won’t make it on time. They’ll be there in 10 short minutes! Check the app for your driver’s location.”
After：“Delivery delayed 10 minutes,Check the app for your driver’s location.”
改進前："哎呀，我們晚點了。""非常抱歉，您的配送員無法準時送達。他們將在短短10分鐘內到達！請在應用程式中檢視配送員的位置。"
改進後："配送延遲10分鐘，請檢視應用程式內配送員位置。"
UX 寫作講究的就是“用詞節省”，一句話能說清就別說兩句。要抵制把所有空白都用重複資訊填滿的衝動
3 Lead with the why 以理由開頭
你如果先告訴使用者這事對他有什麼好處，效果通常會更好。
舉個例子：
我自己超愛玩填字遊戲。我每天都會做，而且還有點小勝負欲。所以當我收到 Apple News+ 拼字遊戲的推送寫著：“Keep your streak going by solving today’s crossword,”“完成今天的拼字，繼續保持連勝紀錄！”時，我立馬點進去了
這條通知之所以有效，是因為它一開始就告訴了你“為什麼要去做這件事”你可以把這個結構理解為：“想得到一件事，先做另一件事”。它先告訴我“為什麼”因為你要繼續連勝。而實現這個目標的方式就是“完成今天的拼字遊戲”這種寫法很萬能，像錯誤提示、推送通知或操作說明。
舉個例子：
假設有個餐廳 App，可以告訴你訂位的最新訊息。如果使用者想收到這些更新，就得輸入他們的電話號碼。
第一版文案：“Enter your phone number to get reservation updates.”“請輸入手機號以獲取訂位更新。”文案有說明也講了好處，算說得明白。
更好的方案：“To get reservation updates, enter your phone number.”“想接收訂位通知？請輸入手機號。”把“接收訂位通知”這段，搬到句子最前面就行，文案一開頭就呈現了接收更新的好處，這在視覺上最醒目，心理上最有影響力。
4 Make a word list 建立一個用詞表
一旦你有了這份詞表，你就可以用它來讓 App 中的用詞更加統一。你希望在 App 裡使用的詞，和你不希望用的詞，然後把它們列出來。表可以採用任何你覺得方便的格式，但我發現用表格來整理最清晰好用。
第一列寫你想用的詞。比如我在做一個遊戲，玩家開始時可能需要選擇一個遊戲內的名字，在這個遊戲裡，我們決定把這個名字叫作 “alias（化名）因為在英文中有“化名”“代號”的意思，更貼合遊戲中角色身份的概念”我會把 “alias” 加入第一列，表示這是我們認可的用詞
第二列寫上那些不用的詞，比如 Handle、User Name、Title 這些，就列在“別用”那邊。你也可以寫點註解，解釋下這個詞具體指什麼。比如我會寫上：“The player’s in-game name, shown to other players, Not used to sign in.”“玩家在遊戲中顯示給其他玩家的名字，不用於登入。”
以後要寫這類提示，我就知道要用“alias”，不能亂換別的詞。這種用詞上的一致性，有助於讓使用者更容易理解和使用 App。
同樣地，我也可以選擇使用 “health（生命值）” 這個詞，並避免使用 “lives（生命數）”、“hearts（愛心圖示）”、“energy（能量）” 和 “stamina（體力）” 等詞，同時附上定義：“用於衡量玩家生命持續時間的數值。”每當我想到一個新的術語，或者發現 App 中已有的詞彙，我都會把它新增到詞表中。隨著詞表不斷完善，它會變成團隊中任何人都能參考的語言資源，幫助大家統一文風
最後，玩家可能會收到一條通知，告訴他們有人發起了一個“對戰請求”（Match-Up）。
不用把做詞表想得太複雜，不用一口氣搞完。就算詞表還沒寫完，也可以馬上用起來，指導你寫內容。比如，在使用者初次設定遊戲時，App 可能會顯示提示： “Choose your alias.”“選擇你的化名。”對於這條提示的說明部分，我可以直接引用詞表中的定義，比如：“這是會顯示給其他玩家看的名稱。”
類似地，如果玩家要找人一起玩，我會寫：“Find an alias.”“尋找一個化名。”這樣可以避免使用者誤以為自己需要輸入郵箱或使用者名稱。
我這裡用的動詞也是“find 尋找”，這個詞我也加進詞表，像動詞這種也要統一。
最後有玩家發起挑戰，你會收到一條對戰通知。通知上寫：“A player with the alias, ‘ExampleAlias’, wants to play.”“一位叫 ExampleAlias 的玩家想和你玩。”
看這三個例子，你會發現我始終如一地使用了 “alias” 這個術語。我從沒用過 “使用者名稱”、“玩家名” 或其他說法，所以使用者每次看到這個詞都會知道我指的是哪一個東西
Put it all together 舉個綜合例子：
刪除填充詞、避免重複表達、以“為什麼”開頭、建立用詞表以保持用語一致性。
我最近入手了一副 AirPods Pro。在設定流程中，有一個聽力測試的選項。這個介紹頁面比我們今天講的其他介面都要長一些，但同樣適用那四條寫作原則。
這個介紹頁的標題是 “Test Your Hearing（測試你的聽力）”。它並沒有寫 “Take a quick and simple hearing test” or "Easily test your hearing.” “進行一次快速簡單的聽力測試” 或 “輕鬆測試聽力” 之類的措辭。
下面的兩個段落則給出了你應該做這個測試的理由，
第一段寫道：“Hearing loss is common and can get worse over time. A five-minute test can identify if you have hearing loss.”“聽力會慢慢變差，且可能隨著時間推移而逐漸加重。一個五分鐘的聽力測試可以幫助識別你是否存在聽力損失問題。”。
第二點是告訴你： “If you have mild or moderate hearing loss, AirPods Pro can provide hearing assistance.”“如果你有輕度或中度聽力損失，AirPods Pro 可以提供聽力輔助。”
這兩段都以“為什麼要測試”為核心邏輯展開。接下來測試會帶你走過幾個介面，這裡展示了其中一些。
注意頁面底部的“Next（下一步）”按鈕。在相同操作中使用相同的按鈕文案（如這裡統一使用“Next”表示“前往下一頁”），可以透過一致性建立使用者信任感。按鈕上的詞也該放進詞表裡統一起來。
“Find a quiet place where you can focus and take the test.”“請找一個安靜的環境專心完成測試。”（標題直接指示）
“Too much background noise can cause inaccurate results in your test.”“背景噪音過大會影響測試準確性。”（說明文字則補充了新資訊，解釋為什麼這一點很重要。）
透過應用這四個小寫作技巧，這些頁面呈現出清晰一致的引導資訊，使整個體驗更輕鬆、更有條理，並讓使用者始終知情和參與。最後大聲讀出你的文案，你一念，就知道哪裡囉嗦、哪裡該精簡。
